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[57] ABSTRACT 

An apparatus and method provide a controlled, dynamically 
loaded, modular, cryptographic filler for integration into a 
base executable having a "slot" minimizing the interface 
between the filler and the base executable, and between 
individual component modules in the filler. Cryptographic 
engines provide for security (privacy and integrity) of data. 
The base executable having potential cryptographic capa- 
bility may rely on an integrated loader to control linking of 
the filler and its modules according to a controlling policy 
set by export or import laws. A base executable may be a 
network operating system having a "slot" for dynamically 
linking the filler and its modules. Modules may be created 
by a third party vendor within controls enforced by the 
loader and a management module in the filler. Asymmetric 
key cryptography may assure that modules have not been 
modified, functionally extended, or created by unauthorized 
sources, and may ensure that keys used in the modules come 
only from authorized sources. The policy may limit each 
module's function, access, and potential for modification or 
substitution. The filler and modules, typically representing a 
relatively small portion of the overall coding required by the 
base executable, may provide strong controls limiting inte- 
gration by providing layered access between modules, and 
excluding direct access to or by them from the base execut- 
able or supported applications. 

46 Claims, 6 Drawing Sheets 
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CONTROLLED MODULAR 
CRYPTOGRAPHY APPARATUS AND 
METHOD 

BACKGROUND 

1. The Field of the Invention 

This invention relates to cryptography and, more 
particularly, to novel systems and methods for controlling 
access, use, and authorization of encrypting applications 
hosted on computers. 

2. The Background Art 

Encryption is a technology dating from ancient times. In 
modern times, encryption of military communications has 
been common. However, since the famous "ENIGMA" 
machine of World War II, cryptography has been used in 
numerous functions. One of those functions is special pur- 
pose software or applications that may be hosted on com- 
puters. Hiding underlying algorithms, limiting access, inhib- 
iting reverse engineering, limiting unauthorized use, 
controlling licensure, and the like may be legitimate uses of 
cryptography. 

Cryptographic Processes 

Modern cryptography protects data transmitted over high- 
speed electronic lines or stored in computer systems. There 
are two principal objectives: secrecy, to prevent the unau- 
thorized disclosure of data, and integrity (or authenticity), to 
prevent the unauthorized modification of data. The process 
of disguising plaintext data in such a way as to hide its 
substance is encryption, and the encrypted result is cypher- 
text. The process of turning cyphertext back into plaintext is 
decryption. 

A cryptographic algorithm, also called a cipher, is the 
computational function used to perform encryption and/or 
decryption. Both encryption and decryption are controlled 
by a cryptographic key or keys. In modern cryptography, all 
of the security of cryptographic algorithms is based in the 
key or keys and depends not at all on keeping any details of 
the algorithms secret. 

There are two general types of key-based cryptographic 
algorithms: symmetric and public-key. Symmetric algo- 
rithms (also called secret-key algorithms) are algorithms 
where the encryption key can be calculated from the decryp- 
tion key and vice versa (and in fact these keys are usually the 
same). These require that a sender and receiver agree on 
these keys before they can protect their communications 
using encryption. The security of these algorithms rests in 
the key, and divulging the key allows anyone to encrypt and 
decrypt data or messages with it. 

In public-key algorithms (also called asymmetric 
algorithms), the keys used for encryption and decryption 
different from each other in such a way that at least one key 
is computationally infeasible to determine from the other. To 
ensure secrecy of data or communications, only the decryp- 
tion key need be kept private, and the encryption key can 
thus be made public without danger of encrypted data being 
decipherable by anyone other than the holder of the private 
decryption key. Conversely, to ensure integrity of data or 
communications, only the encryption key need be kept 
private, and a holder of a publicly-exposed decryption key 
can be assured that any ciphertext that decrypts into mean- 
ingful plaintext using this key could only have been 
encrypted by the holder of the corresponding private key, 
thus precluding any tampering or corruption of the cipher- 
text after its encryption. 
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Most public-key cryptographic algorithms can be used to 
provide only one of secrecy or integrity but not the other; 
some algorithms can provide either one but not both. Only 
the RSA (Rivest, Shamir, and Adleman) public-key algo- 

5 rithm (U.S. Pat. No. 4,405,829), whose security is based on 
the difficulty of factoring large numbers, has been able to be 
used to provide both secrecy and integrity. 

A private key and a public key may be thought of as 
functionally reciprocal. Thus, whatever a possessor of one 

10 key of a key pair can do, a possessor of the other key of the 
key pair can undo. The result is that pairwise, secret, 
protected communication may be available without an 
exchange of keys. Thus, in general, a receiver, in possession 
of its own private key may be enabled to use its own copy 
of a sender's public key, to decrypt data encrypted with a 

15 sender's private key corresponding to the sender's public 
key. 

An asymmetric algorithm assumes that public keys are 
well publicized in an integrity-secure manner. Asender (user 
of a public key associated with a receiver) can then know 

20 that the public key is valid, effective, and untampered with. 
One way to ensure integrity of data packets is to run data 
through a cryptographic algorithm. A cryptographic hash 
algorithm may encrypt and compress selected data. Such 
hash algorithms are commercially available. For example, 

25 the message digest 5 (MD 5), and the message digest 4 (MD 
4) are commercially available software packages or appli- 
cations for such functions. 

A certificate may be thought of as a data structure con- 
taining information or data representing information, asso- 

30 ciated with assurance of integrity and/or privacy of 
encrypted data. A certificate binds an identity of a holder to 
a public key of that holder, and may be signed by a certifying 
authority. A signature is sometimes spoken of as binding an 
identity of a holder to a public key in a certificate. As a 

35 practical matter, a certificate may be very valuable in deter- 
mining some level of confidence in keys associated with 
encryption. That is, just how "good" is an encryption in 
terms of privacy and integrity? That confidence level may be 
established by means of a certificate hierarchy. By certificate 

40 hierarchy is meant a certification process or series of pro- 
cesses for providing certificates from a trusted authority to 
another creator of keys. 

A certificate, being a data structure, may contain, for 
example, data regarding the identity of the entity being 

45 certified as the holder of the key associated with the 
certificate, the key held (typically it is a public key), the 
identity (typically self- authenticating) of the certifying 
authority issuing the certificate to the holder, and a digital 
signature; protecting the integrity of the contents of the 

50 certificate. A digital signature may typically be based on the 
private key of the certifying authority issuing the certificate 
to the holder. Thus, any entity to whom the certificate is 
asserted may verify the signature corresponding to the 
private key of the certifying authority. 

55 In general, a signature of a certifying authority is a digital 
signature. The digital signature associated with a certificate 
enables a holder of the certificate, and one to whom the 
certificate is asserted as authority of the holder, to use the 
signature of the certifying authority to verify that nothing in 

60 the certificate has been modified. This verification is accom- 
plished using the certificate authority's public key. This is a 
means to verify the integrity and authenticity of the certifi- 
cate and of the public key in the certificate. 

6S Cryptographic Policies 

Government authorities throughout the world have inter- 
ests in controlling the use of cryptographic algorithms and 
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keys. Many nations have specific policies directed to files. For example, a need exists to protect an audit trail from 

creation, use, import, and export of cryptographic devices inspection or modification, or both, by a system adminis- 

and software. Numerous policies may exist within a single trator even though the audit trail remains under the system 

government. Moreover, these policies are undergoing con- administrator's physical control. 

slant change periodically. 5 Certain licensing schemes may use various encryption 

Cryptographic policies may limit markets. For example, a modes to prolecl softie againsl piracy by end users an d 

cryptographic algorithm may not be included in software others fo^g^ a distribution chain. Data structures, cryp- 

shipped to a country having laws restricting its importauon. fa methodologies, checks, and other protection 

On the other hand such a ^^^.^^^ mechanisms may be proprietary to a software developer, 

desired, highly marketable, and demanded by the market id 30 NeverthelesSj u ^ ^ er m / chanisms m being de vel- 

another country. Thus, generalized software development, ' ? . 

standardization of software, and the like may become dif- °P e ? 10 support control of he use of application software in 

ficult for software vendors. Moreover, users have difficulties conformity with licenses. Licenses may be provided by an 

attendant with supporting limited installed bases of special- application software provider. The license server may use 

ized software. That is, a sufficient installed base is required Public key cryptography to create and verify signed data 

to assure adequate software. 15 structures. Secret key cryptography may be used to support 

In short, cryptographic use policies sometimes constrain authentication and file encryption, 
the set of cryptographic algorithms that may be used in a Certain applications may provide file confidentiality using 
software system. In addition to restrictions on allowable proprietary, exportable, secret key algorithms. Users in large 
algorithms, cryptographic use policies may also place con- numbers make use of such algorithms. Nevertheless, con- 
straints on the use and strength of keys associated with those 20 siderable interest in breaking such proprietary algorithms 
algorithms. Software shipped or used in any country must be has been successful with certain software. Proprietary 
in compliance with the policies extant. encryption methodologies have been consistently broken, 

Another common aspect of certain cryptographic use given enough time and attention by interested hackers, 

policies is a requirement that a copy of cryptographic keys Certain applications use public key cryptography for 

be stored or "escrowed" with an appropriate authority. digital signatures. Market leaders in software have provided 

However, the mechanisms necessary to satisfy different relatively weak secret key algorithms adopted by others, 

policies can vary greatly. Thus, files written in different applications from different 

Cryptography, especially public key cryptography, pro- vendors, even encrypted files, may be opened by an appli- 

vides certain benefits to software designers. U.S. Pat. Nos. 3Q cation from any of the vendors using the market leader's 

4,200,700, 4,218,582, and 4,405,829 are directed to such secret key algorithm. Within a single product line, a vendor 

technology and are incorporated herein by reference. These of software applications may use multiple algorithms, 

benefits are available in situations where data may be shared. Several, if not a plethora of, algorithms exist, including both 

Many modern software packages (applications, operating secret key algorithms and public key algorithms. Stream and 

systems, executables) are used in businesses or in other 35 block ciphers, as well as hash functions are available and 

networks where multiple "clients" may share a network, well documented in the computer programming art. Also, 

data, applications, and the like. Most modern software certain algorithms are the subject of patent applications 

packages employ cryptography in some form. which may cloud their broadly based use. 

One application for cryptography in network management What is needed is a standardized cryptography method- 

or network operating systems includes authentication. Also, 40 ology for distribution across entire product lines. Moreover, 

integrity of data packets transferred, encryption of files, encryption technologies are needed for permitting a licensee 

encoding associated with licenses for software or servers, of a principal software manufacturer to become a third party 

and license distribution or serving are some of the applica- vendor or value-added distributor capable of producing its 

tions for cryptography. own proprietary software, software additions, or pre- 

Users may be identified and their rights to access may be 45 planned software modules. Currently, software- with- a-hole 

authenticated by means of passwords on a network. Cryp- may provide an operating system with a cryptographic 

tography is typically used to transfer some authentication, module that fits in the "hole" in an operating system, 

integrity, verification, or the like in a secure manner across However, software manufacturers using this technology 

a network that may be open to channel tapping. Public key typically require that a third-party vendor send its product to 

cryptography is typically used in such a circumstance. 50 the principal software manufacturer for integration. The 

Another application of cryptography for authentication manufacturer may then provide all interfacing and wrapping 

involves a single sign-on. For example, a user may need to of the third-party's filler (such as an encryption engine) to fit 

enter a single password at the beginning of a session. This within the "hole" in the software of the manufacturer, 

may remain true regardless of the number of servers that Also, export restrictions exist for encryption technology, 

may eventually be called into service by the individual user 55 Limiting the strength of exported cryptography is estab- 

(client) during this single session. Historically, scripts have lished by statute. To be exportable, such products must meet 

been used to provide a single sign-on, but public key certain criteria (primarily limitations on key size) that effec- 

mechanisms are now being provided for this function. tively prevent the exportation of strong cryptographic 

Users have previously demonstrated that networks may be mechanisms usable for data confidentiality. Moreover cre- 

subject to attack by spoofing of network control packets. 60 ating "cryptography with a hole" is undesirable for several 

This procedure may be demonstrated in playback and in reasons, including export and import restrictions. Cryptog- 

man-in-the-middle scenarios. By such spoofing, users may raphy with a hole is the presence of components specifically 

obtain unauthorized privileges on a network server. Adding designed or modified to allow introduction of arbitrary 

packet signatures, keyed on a per-session basis may provide cryptographic mechanisms by end users. A great escalation 

improved packet integrity. 65 of the difficulty of such introduction, without creating 

File encryption is becoming more available. Such encryp- numerous, individually customized software packages, is a 

tion has particular use in the special circumstance of audit major need today, although not necessarily well-recognized. 
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Certain foreign countries have more stringent regulation Also needed is an alternative to prior art systems that 

of the importation of encryption technology by non- require both a "policy 1 ' and an algorithm implementation to 

government entities. A government may require that any be supplied (even lastly shipped) from the manufacturer of 

imported encryption technology be subject to certain gov- a cryptography engine as the wrapping and certifying entity, 

emmental policies as well as key escrow by some govern- 5 Instead, what is needed is an apparatus having an architec- 

mental agency. Key escrow systems may be easily provided ^re and implementation by which a manufacturer of a 

in software, but integrity and assurance remain difficult. cryptographic engine need not be the same entity as a 

Using only software, reliable key escrow may be impossible, supplier/generator of a policy (e.g. government) to which the 

in the absence of very high assurance. For example, Class cryptographic engine's algorithms are constrained to con- 

B3 or Al may be required of a "trusted computing base" in £ Qrm 

order to protect keys against disclosure or modification. « ^ • 1 JiL r a ■ a a - 

... . Y . *• p 1 ™ t i- Wlli .„ rtT Beneficial, and therefore desirable or needed, is an appa- 

Likewise, protection of algorithms against disclosure or » . a * a 

\ * , • . u i ratus and method having distinct executable modules and 

modification, and escrow against bypass, are also often & , 

required. Under any circurnknees, Software offers few Pol^y data structures sufficiently separable to reduce the 
pactions when compared with hardware solutions. „ cos of _ customing m entire so tware system. Thus, a 
v . , , . „ .. is system is needed that is adaptable to inexpensive customi- 
Customers, whether third-party vendors, distributors, or \, . 4 , , . . , \ 9t 
, * w-uivi , _ . , zation without implementing an embedded policy, 
end users, need information security. International commer- . Z , (L , J 
cial markets need products that may be marketed interna- Also needed is an apparatus and method for separating a 
tionally without a host of special revisions that must be P°»«* from /" to enable flex,buity in the man- 
tracked, updated, and maintained with forward and back- „ p ment and delivery of cryptographic capabilities m con- 
ward compatibility as to upgrades and the like. Meanwhile, 20 fo ™ an ^ with the local regulauons. For example some 
such solutions as key escrow do not receive ready customer method 15 needed . bv ^ hich a manufacturer can produce a 
• no i * i j„ ,„u™ , cryptographic engine, but exclude a policy certificate per- 
acceptance in U.S. markets, particularly where a govern- r ,i_ i a. ^ » a u *u . • 

f . * mitting use of the algorithms implemented by that engine, 

ment is an escrow agent. « . , , . . * . 5* . * t 

^ , ^ • j j ■ . u That is, a method is needed by which a manufacturer or one 

Therefore, what * needed * ;a cryptography apparatus and „ ^ ^ 

method that may be mass produced in a variety of produc s pohcy authorization, certification, and verifi- 

across an enure product Ime. A ecology, or product that caiion * , oaJ regukt ' ions . 

can be sold in identical form both domestically and abroad b 

is highly desirable. An encryption method and apparatus are BRIEF SUMMARY AND OBJECTS OF THE 

needed that may provide improved methods for security and 30 INVENTION 

integrity of data provided by ^ff^^^^ T In view of the foregoing, it is a primary object of the 

keys themselves, without requiring trust between sender tQ an apparatus ^ method com , 

and receiver. prising distinct, controlled modular cryptography modules 

Also needed is a key escrow mechanism for corporate ^ * d ^ structures 

environment For example file encryption by an employee 35 {& & object of ^ inveatkm to Me M 

will usually be required to be subject to an escrow key in the 7 4 . Jf J , • 1 A - t a i_ „ 

. r - * 4 , A 1 • . *™„f™ ,J*u c;„ ratus and method for dynamic loading of modules into a base 

possession of the employer Also in conjunction with sig- ^ m a mann J t0 t SUD Wution, modification, 

nature authorities, delegation of such authority may be ^wuiaui* m f » » 

Udl " , . V & . t M« I ^t 1 pi,ce P,rh mr extension, or misuse of algorithms implementable by the 

useful in a corporate environment. Nevertheless, each cor- & r 

porate user may be viewed as a secondary (vendor) level 40 mo u es * . 

desiring to have its own encryption and escrow control of all H « another object of the invention to provide protection 

copies of all keys against access or use of algorithms in a cryptographic 

What is needed is a method for producing cryptographic absent P ro Pf r * a P olic y specifically autho- 

applications that may be customized individually, from nzed 10 <***™* lhose algorithms, 

individual modules. That is, what is needed is modules that 45 U is another ob J ect of the invention to constrain the 

may be used to limit the capabilities of cryptographic internal generation of cryptographic keys, loading of cryp- 

applications without proliferating individual customized tographic keys from external sources and usage of keys so 

software products that may become very difficult to as to conform to an applicable national policy regarding the 

maintain, upgrade, support, and the like. What is needed is sources, usage, escrowing, size, and all other relevant 

an apparatus and method that can separate a cryptography 50 attributes °f sucn - 

application or a cryptography filler for an operating system It is another object of the invention to obtain such 

"slot" into modules. Modules need to be configured to constraints on internal generation, so as not to be dependent 

minimize the extent of interfaces and the amount of code on the cooperation or participation of any third-party 

that must be interfaced. Modules should minimize the num- vendors, distributors, or end users of cryptographic modules, 

ber of exclusions from a system that must be patched or 55 It is another object of the invention to provide an appa- 

replaced in order to enable the software system to satisfy ratus and method having policy flexibility, such as a plurality 

relevant cryptography usage policies. of policy certificate authorities and a plurality of policies, 

What is needed also are an apparatus and method effective ranging, for example, from a minimally controlled policy 

to enable a manufacturer of a cryptographic engine to administered by a manufacturer, to a maximally controlled 

produce a single implementation of a modular package 60 policy administered by a regulatory authority such as a 

embodying particular cryptographic algorithms. The manu- government agency. 

facturer should remain able to include that implementation It is another object of the invention to provide this stated 

in all versions of a software product. This should be true policy flexibility in a manner that implements multiple 

regardless of different key usage policies mandated by policies so as to enforce the most restrictive set of limitations 
various regulatory authorities. It should be true regardless of 65 obtained from an intersection of the policies, thus imple- 

a requirement for disabling of certain of the included algo- menting the most restrictive individual features (e.g. 

riihms. limitations) selected by comparing all applicable policies. 
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It is another object of the invention to provide an appa- By contrast, an apparatus and method in accordance with 
ratus and method in which a manufacturer of a crypto- the invention may provide for a universal "base executable" 
graphic module may provide distinct implementations of a comprising a software system for operating on a computer, 
module, according to di fife rent policies, by modifying a A software development kit may be provided with certain 
minimal portion, or even a separate modular portion, such as 5 authorizations to an agent, vendor, distributor, or partner, 
a software key, or a certification signature or authentication. j^g authorizations may be provided as certificates permit- 
It is another object of the invention to provide a controlled ting the agent to create software modules and wrap them 
modular cryptography apparatus and method having without their contents being known, even to the original 
multiple, specialized modules provided with restrictive manufacturer of the "base executable" or the software 
interfaces between those modules enforceable to control 1Q dcvc i opmcnt kit. Such a system may then include a con- 
access to and between the modules. strained policy obtained by the agent, vendor, etc., in coop- 
It is another object of the invention to provide an appa- eration with a government, to meet the import laws of the 
ratus and method involving digitally-signed cryptographic country 0 f sa le of the entire package, the software "base 
fillers (software modules) divided or modularized into spe- executable," modules from vendors, and an authorizing 
cialized component modules effective to minimize the guch a m ^ afl (development 
amount of code that must be excluded from a genenc system third J vahie _ added ^ module vendor> 
in order to enable the system comprising the apparatus and distributor) to provide sealed encryption algorithms. The 
method to satisfy ' Jinlity of potential, relevant crypto- P remato ^ only ^ 0 lhe a * enl> fanner, 
graphic usage policies. distributor, etc.) although accessed for Unking using keys 

It is another object of the invention to provide an appa- torfzed b ^ mam f facturer of me base executable, 

ratus and method implementing a cryptographic engine ' 

having a single filler comprising certain implementations of The software development kit may provide for an autho- 

particular algorithms, which filler can be implemented in all rization mechanism, such as a certificate of authority imme- 

(or a relatively broad range of) versions of a product, diately identified with the software development kit and the 

regardless of different key usage policies mandated by Any "base executable" may then verify any module 

regulatory authorities and under which the apparatus and 25 &°rn any vendor to determine that the vendor has produced 

method may be used a raodu l c m accordance with policy constraints imposed on 

It is another object of the invention to provide a secure, the «>^™ ^TT** 1 ^ ^ ^ <W 

certifiable, verifiable apparatus and method by which the executable produced by the manufacturer 

manufacturer of a cryptography engine may be distinct from Thus, a universal "base executable" may be exportable by 

a manufacturer of a software package incorporating the a manufacturer and importable by a distnbutor or reseller. A 

engine (or other module), and a supplier of a policy to which distributor may be responsible to obtain the proper licensure 

the engine's algorithms are constrained to conform. for cryptographic equipment and functionality. The "base 

It is another object of the invention to provide an appa- executable" can verify that all modules by a distributor come 

ratus and method having a policy separated from a cryptog- „ ^ a development kit operating within its bounds 

raphy algorithm, in which a manufacturer may produce a of policy authorization and other permitting functionality, 

cryptographic engine securely disabled absent the policy, yet In short, the "base executable" knows how to recognize a 

which, after the policy is properly provided, may then enable valid signature provided from a module created on a proper 

use of the previously disabled engine for the purposes software development kit. A software development kit may 

allowed by and in compliance with the constraints embodied 4Q produce or generate proper digital signatures. The agent's, 

in the policy. distributor's, or partner's module product may then carry the 

Consistent with the foregoing objects, and in accordance proper signature. Therefore, the "base executable" may 
with the invention as embodied and broadly described recognize and run only those modules having valid signa- 
herein, an apparatus and method are disclosed in certain tures corresponding to software development kit "tool- 
embodiments of the present invention as including a con- 45 boxes" of known, authorized agents or distributors, and m 
trolled modular cryptography system. accordance with authorized policies. 

A principle feature provided by an apparatus and method Another feature of an apparatus and method in accordance 

in accordance with the invention includes limitation of with the invention may be a null engine. A null engine may 

software integration. For example, a software integration be provided by a manufacturer with any "base executable" 

limiter may provide a cryptographic operating system with 50 (principal software product, operating system), having no 

a "slot." That is, an operating system may be thought of as enabled cryptographic capability. Nevertheless, the null 

a block of executable instructions storable in a memory engine may support all interfaces required by a "slot" in the 

device, and loadable on a processor. base executable, and all functionalities except cryptographic 

A software integration limiter in accordance with the capabilities required by a "filler." Thus, for example, an 

invention may provide an architecture and coding to limit 55 operable software system may be delivered having no cryp- 

the integration of coding required to fill a "slot" left within tographic capability, simply by providing a filler including a 

an operating system. Thus, the operating system or other null engine to fill the "slot" within the software product 

software cannot operate at all, or may be configured to not (operating system, base executable) provided by the manu- 

operate with cryptographic capability, absent an authorized, facturer. 

added software "filler" filling the "slot". 60 Another feature of the apparatus and method in accor- 

Another feature available in an apparatus and method in dance with the invention may be flexible key escrow capa- 

accordance with the invention may be a vendor-constrained, bility. This feature may be thought of as a modular key 

remotely sealed, software integration limiter. For example, escrow method. Escrow capability may escalate from a self 

prior art systems may require that a manufacturer receive, escrow. For example, an individual company, individual 

license for import, and wrap the code of value-added resell- 65 user, or the like, may hold and control all keys. At an 

ers and vendors, incorporating the codes into a cryptograph!- opposite extreme, an escrow of a key may reside with some 

cally enabled software product. other independently authorized escrow agent. A key escrow 
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may reside with a governmental agency itself as required in which a digital encryption standard using 64 bits exists 

some countries. within the library. Nevertheless, the more powerful standard 

Another feature of an apparatus and method in accordance may not be implemented, absent the proper keys which are 

with the invention may include cryptographic wrapping of themselves encrypted and maintained under the control of 

keys. That is, wrapping may be thought of as tamper 5 the manufacturers and the policies provided, 

proofing (authentication) and encrypting (secrecy Thus, the above objects may be met by one or more 

protection) a key. Prior art system's keys may be simply bit embodiments of an apparatus and method in accordance 

strings of sufficient length and complexity to reduce the with the invention. Likewise, one or more embodiments of 

probability of their being deciphered. an apparatus and method in accordance with the invention 

Here, a holder's identification and a certification authori- 10 may provide the desirable features as described, 

ty's identification may be applied to a key itself. The digital DESCRIPTION OF THE DRAWINGS 
signature of the certifying authority may enable verification 

of such certification. The keys may be centrally managed, The foregoing and other objects and features of the 
such as by a management module in the "base executable" present invention will become more fully apparent from the 
from a manufacturer. Such a module can therefore restrict 35 following description and appended claims, taken in con- 
creation, distribution, and use of keys, especially within a junction with the accompanying drawings. Understanding 
network or internetwork. that these drawings depict only typical embodiments of the 
Another feature of an apparatus and method in accordance invention and are, therefore, not to be considered limiting of 
with the invention may include quality-graded certificates. its scope, the invention will be described with additional 
The certificates may be generated by distributors (value- 20 specificity and detail through use of the accompanying 
added resellers, module vendors, agents, partners). drawings in which: 

However, the certificates may provide a "pedigree" indicat- FIG. 1 is a schematic block diagram of modules arranged 

ing an integrity level of the cryptography provided by a m one embodiment of an architecture for an apparatus and 

certificated software product. Thus, a purchaser of software method in accordance with the invention; 

who will become a user or owner (holder) may know the FIG 2 ^ a schematic block diagram of an apparatus in a 

cryptographic strength (algorithm, key length) or quality networ k for hosting and implementing the embodiment of 

(integrity; value limit of assurance) of the systems used or pjQ ^ 

created, with a verification that cannot be forged. FIG.' 3 is a schematic block diagram of an example of 

Another feature of an apparatus and method in accordance 3Q cxecutables operable in a processor for implementing the 

with the invention may be provision of cryptographic embodime nt of the invention illustrated in FIG. 1; 

engines that are not independently usable. For example ^ ^ m mustfati les 

cryptographic engines may be " m P^^ of data structures in a memory device corresponding to the 

with, wrapped, non-linkable modules that can only be used u f mr^ i-i 

in a filler to fill a "slot" in a base executable (principal apparatus or hw. i^, 

software application) from a specified manufacturer. Thus, FIG. 5 is a schematic block diagram illustrating certificate 

unlike the prior art where a cryptographic engine obtained hierarchies for implementing one embodiment of an appa- 

by a vendor or third party may be used with any software, ratus and method in accordance with the invention; and 

cryptographic engines made in accordance with the inven- FIG. 6 is a schematic block diagram of certain operational 

tion may not be enabled absent verification of their integrity, 4Q processes for one embodiment of a controlled modular 

applicability, policy, or the like by a base executable cryptography system implemented in accordance with the 

(principal software product). For example, a base invention. 

executable, such as an operating system or other nFTATl FD DFSCRlPTiON OF THE 

manufacturer-supplied module may verify any and all mod- ^m^^^^rLvm^ 

ules attempting to link with the base executable and vice 45 PREFERRED EMBODIMENTS 

versa. It will be readily understood that the components of the 

Another feature of an apparatus and method in accordance present invention, as generally described and illustrated in 
with the invention may be constraining the linking of the Figures herein, could be arranged and designed in a wide 
modules to a specific class of module, or within a specific variety of different configurations. Thus, the following more 
class of module, through the use of cryptography. Thus, for 50 detailed description of the embodiments of the system and 
example, a hierarchy of linking may be created within method of the present invention, as represented in FIGS. 1 
individual software modules, so that all modules may link through 6, is not intended to limit the scope of the invention, 
only to peers (associated modules in one filler) and may not as claimed, but it is merely representative of certain pres- 
necessarily be able to link directly with selected modules of ently preferred embodiments of the invention, 
the total group of peer modules with the same filler. For 5S The presently preferred embodiments of the invention 
example, an application or library module may not bypass a will be best understood by reference to the drawings, 
limiting manager module to interface with a cryptographic wherein like parts are designated by like numerals through- 
engine module. out. Reference numerals having trailing letters may be used 

Another feature of an apparatus and method in accordance to represent specific individual items (e.g. instantiations) of 

with the invention may include a restriction of the use of 60 a generic item associated with the reference numeral. Thus, 

cryptography, by use of cryptographic methods. Thus, for a number 156a, for example, may be the same generic item 

example, a manufacturer may produce a library of crypto- as number 156/, but may result from a different version, 

graphic functions that is much stronger than what would instantiation, or the like. Any or all such items may be 

ordinarily be exportable under the laws of the United States, referred to by the reference numeral 156. 

or importable under the laws of receiving countries. 65 Referring to FIGS. 1-3, a method and apparatus for 

For example, if only a 40-bit engine may be exported providing controlled modular cryptography is illustrated in 

under normal circumstances, a library may be created in software modules, supporting hardware, and as executables 
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distributed through a processor. Reference is next made to The subdivision of modules 13 in a layering architecture 
FIGS. 4-6, which illustrate in more detail, schematic block (e.g. layer 18 is manager modules 18 including modules 42, 
diagrams of certain preferred embodiments of an apparatus 44, 46) great flexibility may be obtained. Since modules 13 
and method for implementing controlled modular cryptog- are dynamically bound by the loader 90, and managed by a 
raphy in accordance with the invention. Those of ordinary s manager module 18, the modules 13 may be modified or 
skill in the art will, of course, appreciate that various exchanged as needed and as authorized. Management mod- 
modifications to the detailed schematic diagram of FIGS. ules 18 not yet envisioned may be added in the future, 
1-6 may easily be made without departing from the essential without revising the base executable 14, or even the filler 12, 
characteristics of the invention as described. Thus, the outside the module 13 in question. 

following description of the detailed schematic diagrams of 10 For example, a management module 18 may support 

FIGS. 1-6 is intended only as an example, and it simply cryptographic-token PIN (personal identification number) 

illustrates certain presently preferred embodiments of an management, not available in an initially purchased product^ 

apparatus and method consistent with the invention as 14. Another example may be added support for policy 

claimed herein. management enhancements, such as providing separate APIs 

Referring now to FIGS. 1-6, a controlled modular cryp- 35 (application programming interfaces) for encrypting and 

tography (CMC) process 12 or method 12 may be imple- decrypting ubiquitous financial data used by banks, 

mented using a plurality of modules 13. The CMC process New functionality, not typically used or required in cur- 

12, alternately referred to herein as CMC 12, may be rent practice by banks, may include a separate key type or 

embedded within another executable 14 such as a network specifically for financial data. Such keys 156, 160 may 

r operating system 14. The network operating system 14 may 20 De relatively stronger than general keys 156, 160, while use, 

include an operating system proper 15, what would conven- holders, data types, and the like may be restricted by policies 

tionally be known in a generic operating system as the 164 crafted for special financial purposes. Thus financial 

operating system 15. keys 156, 160 may be managed differently from other 

The operating system 14 may also have provision for general types of keys 156, 160. 

insertion of a pre-processor 92 in a conventional hole 93. 25 Referring now to FIG. 2, a network 56 may comprise a 

By contrast, the CMC 12 is not accessible by third parties /plurality of nodes 58 (e.g. clients 58). Although the clients 

at a pre-processor slot 93. Third parties may create pre- 58a, 58fo, 58c are illustrated, the computers of the clients 58, 

processors 92 having direct access to the operating system server 62, and router 64 may also be thought of as being 

15. Prior art cryptographic engines are often mere pre- hosted, programmed to run on, any computer 58, 60, 62, 64 

processors interposed between applications 40 and the oper- 3 on a network 56. Likewise, the CMC 12 may be pro- 

ating system 15. Likewise, the unauthorized installation by grammed into any of those computers 58, 60, 62, 64. By 

a third party of a cryptographic engine in a pre-processor slot node is meant a computer on a network 56 in its broadest 

93 may be rendered virtually impossible by the CMC 12 and sense. 

operating system 15. Instead, the CMC 12 may be loaded 35 Likewise, the host 60 or server 60 may actually be 

into the base executable 14 such as the operating system 14 programmed to function as one of several servers 62 or 

in a manner that embeds the CMC 12 into the operating routers 64. As a practical matter, the server 62 may be 

system 14 and prevents interfacing by any third party to the replaced by the server 60. A node 58 may include some or 

cryptographic capability of the CMC 12. (See FIG. 3.) all of the structural contents illustrated for the server 60. For 

Referring now to FIGS. 1-6, and more particularly to 4Q example, if every node 58 comprises a computer, every node 

FIG. 1, the controlled modular cryptography 12 may include 58 may have any or all of the components 7ft-86. 

library modules 16 for interfacing with applications 40. A network 56 may include a backbone 66 for intercom 

Each library module 16 (X library 16, or simply library 16) necting all the nodes 58 or clients 58. The router 64 may also! 

may be application-specific. connect to one or more other networks 68. The network 68 | 

The loader 90 (see FIG. 3) provides layering (hierachical 45 may be a local area network (LAN), wide area network 
linking) or nesting (recursive loading or linking) of inter- (WAN) or any size of internetwork, 
faces. The layering may effectively prevent applications 40 The server 60 may include a CPU 70 or processor 70 for 
and an operating system proper 15, for example, from hosting the operating system 14 and CMC 12. As a practical 
interfacing directly with controlling modules 13 (e.g. man- matter, a random access memory 72, or RAM 72, may 
ager modules 18) or with engines 20 (e.g. cryptographic 50 temporarily store, in part or in total, any or all codes and data 
engine 50). The loader 90 may do this directly by dynamic associated with executables within the CMC 12. For 
loading of modules 13, enforcing restrictions on access to example, during operation of the CMC 12, individual mod- 
interfaces between levels 16, 18, 20, 22, 15 illustrated in ules 13 might be stored, or a portion thereof might be stored 
FIG. 1. in the RAM 72. 

Manager modules 18 as well as the original loader 90 55 The CPU 70 and RAM 72 may be connected by a bus ' 

loading a filler 12 (CMC 12) may assure that a layering Also on the bus may be operably connected a network card 

hierarchy is enforced between modules to limit interfaces. 76 or network interface circuit 76 (net card 76), one or more 

Manager modules 18 may interface with library modules 16. input devices 78, and output devices 80, or the like. Addi-_ 

The manager modules 18 may also interface with the tional memory devices such as a read-only memory 82 

cryptographic engines 20, or engine modules 20. Support 60 (ROM 82) and a storage device 84 (such as a hard disk 84), 

modules 22 may interface with engine modules 20 also. may be operably connected to the bus 74 to communicate 
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Library modules 16, manager modules 18, and support data with the processor 70. <—V 
modules 22 may interface with the operating system 15 in Additional ports 86 may be provided as appropriate . As a I 
one preferred embodiment of an apparatus and method in practical matter, the input device 78 and output device 80 I 
accordance with the invention. The engines 20 may be 65 may merely represent ports for accessing one or more S 
enabled to interface only with other modules 13, and not available input or output devices 78, 80. Similarly, with the _J 
with the operating system 15. distributed nature of hardware and software in a modern 
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computing environment, other devices may be accessed, 13. Other managers 46 may also be provided. For example, 

through the net card 76, elsewhere on the network 56. manager modules 46 may alter methods of policy enforce- 

Referring to FIG. 1 once more, the interfacing between naent for the escrow of keys 156. 
modules 13 may be restricted. Such a restriction may In one embodiment, the CMC 12 may be provided with a 
provide additional assurance that the CMC 12 may not be S null engine 48. A null engine 48 may be operated to interface 
misused, modified, or replaced improperly. Therefore, cer- at the engine interface 30 and the support interface 32 while 
tain of the modules 13 may have operating system interfaces providing no enablement of cryptographic capability. Thus a 
24. For example, the interfaces 24a, 24£>, 24c represent the base executable 14 may be fully functional otherwise, 
interfaces between the libraries 16, managers 18, base 22, including all necessary interfaces to the filler 12 (CMC 12), 
respectively, shared with the operating system 15. 10 while having no enabled cryptographic capability. The inter- 
In the illustrated embodiment of FIG. 1, the engines 20 faces 26, 24 to the filler 12 may be as secure as if the 
share no interface with the operating system 15. Instead, the dynamically loaded modules were manufactured as inte- 
engines 20 may interface through the base support 22. grated portions of the base executable 14. 
Library interface 26 represents the interface between library Thus, an apparatus 10 may be provided as a base execut- 
16 and applications 40. The library interface 26 may be 15 able 14, having fully imbedded support for a cryptographic 
considered to be an interface between the CMC 12 and engine 20. However, the presence of a null engine 48 
applications 40. accommodates all the proper interfaces 30, 32 while actually 

The libraries 16 may be structured to interface directly providing no cryptographic capability, 
with applications 40. The foundation 54 or the CMC foun- Thus, a CMC 12 (filler 12) may be provided with a base 
dation 54 may be thought of as the core of the CMC 12. The 20 executable 14, including a null engine 48, exhibiting mini- 
managers 18 provide cryptographic facility as well as con- mal differences with respect to the operating system 15 as 
trolling access to and between modules 13 especially in the compared to another cryptographically -enabled product, 
core 12. The interface between the CMC enforcement by the Meanwhile, other engines 50 may be provided by a m ami - 
foundation 54 and applications outside the base executable "facturer or a third party vendor authorized to create crypto- 
14 is moved away from the manager interface 28 by the 25 graphic engines 20 according to some policy and autbori- 
library interface 26 and interposed libraries 16. Thus, appli- zation. 

cations 40 are not permitted to interface directly with the ^\ b ase support module 52 may provide some minimal set 

(controlling) management modules 18. This farther avoids 0 f operating system instructions for the engines 20. That is, 

creation of cryptography with a hole. ^ in general, the engines 20 need some access to the operating 

The manager interface 28 represents the interface between system. Nevertheless, for providing the assurance that 

the manager modules 18 and the library modules 16. The engines 20 may not be created, modified, extended, 

engine interface 30 represents the interface between engines circumvented, inserted, or the like, in an unauthorized 

20 and the manager modules 18. The support interface 32 fashion, the support module 52 may intervene. Thus, the 

represents the interface between the engines 20 and the 35 base module 52 may provide access to some limited number 

support modules 22. of functions from the operating system 15 for the engine 20. 

In general, communications 38 may be calls from upper Referring now to FIG. 3, an operating system 14 may be 

layers 40, 16, 18, 20 shown to lower layers 16, 18, 20, 22, implemented in one embodiment of an apparatus and 

respectively, in FIG. 1. Each layer 16, 18, 20, 22 may method in accordance with the invention to include a loader 

properly execute without requiring anything from a layer 18, 4Q 90. The loader 90 may be associated with the operating 

20, 22, 15, respectively, below, system proper 15. The functional responsibility of the loader 

For example, in one embodiment of an apparatus and 90 may be to dynamically load and properly link all modules 

method in accordance with the invention, one library 16 may 13 into the CMC 12 (filler 12), for example, installing (e.g. 

be an audit library 34. For example, the audit library 34 may embedding) them into the operating system 14. 

have functional responsibility for encrypting security audit 45 More specifically, the loader 90 may be tasked with the 

data for storage. The underlying data may correspond to functional responsibility to provide all proper linking 

events of significance to audit executables. The network 56 between modules 13. Linking may be enabled on a layer to 

itself may be managed by an individual acting as a system layer (or interface 28, 30, 32) basis rather than on a module 

manager, yet the audit data encrypted by the audit library 34 by module basis. For example, a binding may exist between 

may be inaccessible to the system manager. 50 any two modules 13 in a layer (e.g. layer 18, or layer of 

Other libraries 36 may be provided. Each of the libraries manager modules 18). Binding may also exist between any 

36 may be application-specific. In one presently preferred module (e.g. modules 42, 44, 46) in that layer (e.g. layer of 

embodiment, each of the applications 40 interfacing at the managers 18) and another module (e.g. modules 48, 50) in 

library interface 26 may have an associated, unique, library a layer (e.g. layer 20, or layer of engines 20) sharing an 

module 36 provided. 55 interface (e.g. interface 30) with that layer (e.g layer 18). 

The key generation manager 42 may create symmetric Specific modules 13 need not be individually limited and 

keys or asymmetric key pairs provided to cryptographic controlled by the loader 90. In one embodiment, individual 

engines 20. The key generation manager 42 may also modules 13 may be bound. Thus, for example, only those 

perform the escrow function of the escrow archive 170 (see functional features authorized for a key generation manager 

FIG. 6). Abase manager 44 may provide enforcement of 60 42, or a cryptographic engine 50, might be enabled by being~\ 

policies 164. properly bound (linked). s~~^ 

Access to modules 13, such as the engines 20, and access In one example, a cryptographic engine 50 may be7 

to cryptographic algorithms within engine modules 20, and manufactured to contain numerous algorithms. However^ 

the like, maybe enforced by the manager modules 18. In one according to some policy 164 (see e.g. FIGS. 5, 6) incor- 

embodimeot of an apparatus and method in accordance with 65 porated into a certificate 154, a manager 46 and the loader 

the invention, the base manager 44 may provide an enforce- 90 may limit linking (binding) to an enablement of algo- 

ment function with respect to all functions and all modules rithms and engines 20. A manager module 46 may also 
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control key usage, including length and function. Function may be thought of as an instantiation of a certificate 154 

may be distinguished between, for example, encryption associated with the operating system 14 and its included 
versus authentication. Use may be controlled based uponTl CMC 12. The certificate 118 may be thought of as the data 

for example, a manufacturer's (of the module 13) signature I certifying the holder of a certificate operating and using the 
162 and key type. ^% data structure 116. By certificate 120 is meant data provided 

The operating system 15 may support a selection of m a certificate issued to the holder, 

preprocessors 92 such as the audit event filter 92. Pre- A certificate 118, 120 may also be thought of as a binding 

processors may be adaptable to fit in a hole 93 readily of a hokJer ID ^ U2 to a pubHc key u6> 136j certified 

available for the purpose. In one ^currently preferred embodi- b a £ K 124 134 of a ^Xying authority. An 

ment of an apparatus and method in accordance with the 1Q ^ ( 1$2b) qj aumori and a hoMer ( ls2d) 

invention, a CMC 12 is not adaptable c .be implernen ed as cach ^ * J £ ^ J 

a preprocessor 92. Instead, the CMC 12 may be limited to ± * > £ > 

mterfacing only with the operating system proper 15 as . JOi>uw \ & / \ & /> r 

illustrated in FIG. 1, and only after proper loading by a lively. 

loader 90. Even within the operating system 15, the CMC 12 When discussing authorities, holders, receivers, and the 

may be limited to interfacing with the operating system 15 15 like, it is important to realize that such an authority, holder, 

through a limited number of interfaces 24. sender, receiver, or the like may actually be a hardware 

As a practical matter, certain applications 94 or programs device, or a software operation being executed by a hard- 
94 have resident portions within the server 60 hosting the ware device. Any hardware device, operating software, or 
operating system 14. For example, a file system 98, a name on data structure in a memory device may be owned, 
service 100, a work station 102 and the like may have 20 controlled, operated, or otherwise associated with an inch- 
resident portions operating in the processor 70. Even if, for vidual or an entity. Nevertheless, insofar as the invention is 
example, a server 62 is operating as a file server, the file concerned, names of such entities may be used to represent 
system 98 may be a portion of a file server executable that the hardware, s sofiware, data structures, and the like con- 
needs to be resident within the processor 70 of the server 60 tolled or otherwise associated with such entities, 
in order for the server 60 to communicate with the server 62 As a practical matter, a certificate 118 authenticating the 
over the network 66. rights of the CMC 12 may contain an identification record 

Generally, certain data may need to flow into and out of 122 identifying the holder (the specific instance of the CMC 

the operating system 14. Accordingly, a number of channels 12), a signature record 124 verifying the higher certification 

96 or data flow paths 96 may need to exist. As a practical authority upon which the holder depends, and a public key 

matter, the channels 96 may be comprised of either paths, record 126 representing the public key of the holder. The 

data itself, or as executables hosted on the processor 70 for private key 128 may be very carefully controlled within the 

the purpose of providing communication. Thus, an audit file CMC foundation 54 using encryption for wrapping. The 

104 an accounting log 106, an archive file 108, and the like private key 128 may be associated with the holder (CMC 12) 

may be provided as channels 96 for communication. „ and is the private half 128 of a key pair including the public 

Thus, the overall operating system 14 along with the key 126. Thus >, by means of ^the private key 128, the holder 

applications 94 and channels 96 may be thought of as a local may create the signature 134 in the certificate 120 for 

system 110 or the local processes U0. These local processes another ^ of me kev P air 136 > 138 * 

110 operate within the CPU 70. The CPU 70 is a processor Meanwhile, a certification authority 152 (see FIGS. 5-6) 

within the server 60 or host 60. As a practical matter, the 40 may provide to a holder or sign 166, the certificate 118 (one 

processor 70 may be more than a single processor 70. The of the certificates 154). The certificate 120 may reside in 

processor 70 may also be a single processor operating another computer or simply be allocated to a different thread 

multiple threads under some multitasking operating system or process than that of the certificate 118. 

15, As a practical matter, a private key 128, 138 may be 

Data representing executables or information may be 45 protected by physical security. Therefore, a private key 128, 

stored in a memory device 72, 82, 84. Referring now to FIG. 138 may typically be controlled and be cryptographically 

4, one may think of a dynamic data structure 114 or an wrapped except when dynamically loaded into a dynamic 

operating system data structure 114 storable in an operable data structure 114. 

memory 116. That is, for example, the operating memory The private key 128 may be used to certify an identifi- 

116 may be within the RAM 72 of the host 60. All or part 50 cation record 132 identifying a new holder. A signature 134 

of the data structure 114 may be moved in and out of the created by use of the private key 128 may verify the 

processor 70 for support of execution of executables. authenticity and quality of the certificate 120 and public key 

The data structure 114, may be dynamic. The modules 13 136. The public key 136 may be thought of as the matching 

for example, may be dynamically loadable, such as network key 136 to a key pair including the private key 138 created 

loadable modules. Thus, for example, a host 60 may operate 55 by the new holder of the certificate 120. That is, one may 

without having any fixed, storable, data structure 114. That think of a new holder, as a process, or an individual, issuing 

is, no static data structure need be assembled and stored in a public key 136 certified by the signature 134 of the private 

a manner that may make it vulnerable to being copied or key 128 as duly authorized to create software which func- 

otherwise inappropriately accessed. The data structure 114 tions within the limits of a policy 140. The certificate 118, 

may only exist dynamically during operation of the proces- $o an instance of a certificate 154 held by the CMC 12, may 

sor 70, and even then need not all exist in the memory device have a signature 124 by a higher certifying authority 152. 

116 (e.g. RAM 72) simultaneously at any time. Thus, A policy 130, 140 may limit the authorization of the 

additional assurance is provided against misuse, and abuse holder identified by the ID 122, 132 and certified by the 

of data and executables in a CMC 12 associated with an digital signature 124, 134. A policy 130, 140 may incorpo- 

operating system 14. 65 rate the limitations governing the use of algorithms in 

The data structure 114 may contain a certificate 118 and engines 20, for example. Thus, a policy 130, 140 may be 

certificate 120. A certificate 118, for the purposes of FIG. 4, thought of, for example, as the rules enforced by a manager 
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module 18 controlling access to and from a module 13, such 133 may be provided to identify a certifying authority 152. 

as an engine (e.g. cryptographic engine SO). Each public key 136, 126 may be represented as bits of a 

Each policy 164 (e.g. 1644, see FIG. 5) may contain a segment 136, 126 in the frame 142. The signature 134, 124 

digital signature 163 (e.g. 163rf) of the certifying authority ° f a ff authority 15 2 may be represented as another 

152 (e.g 1526) above the holder 152 (e.g. 152<0 of the s ^tto<***lWll*™n\hc1^142.T^<y 

-•i . i*A s haj\ a i- iA 7 1^ tl 0 140, 130 may be represented by another segment 140, 130. 

ceruncate is* ie.g v»a } ana policy w (.eg. i W > . ne U8 m may fa ' ave 

corresponding (e.g. even 

policy 164(e.g U4d) may thus be bound to the correspond- k& m 140 J undcr ^ to e ^ e . 

ing certificate 154 (e.g. IStd) by the digital signature 163* ^ ^ key m m ^ ^ ^ ^ m 

In one embodiment, policies 164 may be generated by a 132> 12 2. A public key 136, 126 is typically published to 
separate policy authority using a policy authority digital 10 other functions or to other entities, just as a certification 
signature 129, 139 (see FIG. 4). A policy authority signature authority's 152a, 1526, 152c public key 160a, 160b, 160c is 
129, 139 binding a policy 130, 140 to a certificate 118, 120 published. Thus, a certifying authority's public key 136, 126 
need not be different from a certificate authority signature is illustrated in FIG. 4 as being separate from the frame 142. 
124, 134, but may be. This is analogous to the certification The public key 136, 126 may be embedded in another 
authorities 152 for certificates 154. Thus, the policies 164 15 certificate held by a certifying authority. Similarly, a hold- 
may be provided and signed 166 by a certifying signature er's private key 138, 128 may be maintained with utmost 
163 binding the policy 164 to a corresponding certificate security. Therefore, a holder's private key 138, 128 is not 
154. Nevertheless, the policy 164 may be certified by a available with the holder's published public key 136, 126, 
policy authority 129, 139 other than the certificate authority except to the holder. Thus, a holder* s private key 138, 128 
152 creating the corresponding certificate 154. 20 may not actually be generally available or associated with 

Referring to FIGS. 4-6, the certificate 118 may include the certificate 120, or certificate 118, respectively, in the 

identification records 122. The identification records 122 frame 142. 

may contain information recursively identifying the higher Referring now to FIGS. 4-6, the certificate hierarchy is 

certifying authority (e.g. 152a, 1526), as well as the holder illustrated, as is the implementation of operational keys 156, 

(CMC 12) certified. However, the signature 124 may be 25 160. Reference numerals having trailing letters, may be 

verified by using the public key of the higher authority 152. thought of as specific examples of a generic structure or 

For example, the signature records 124 may comprise a function associated with the reference numeral alone. Thus, 

signature of a signature root authority 1526 or higher a certifier or certification authority 152 is a general 

authority 152a certifying, which authority is known by the ^ expression, whereas the root certifier 152a and the CMC 

identification 133. The private key 128 may be thought of as signature root 1526 are specific examples of a certification 

a key by which the holder (e.g. the CMC 12) creates authority 152. 

signatures 134 for certificates 120 associated with, for In general, an authority 152 (e.g. root certifier 152a), may 

example the key generation module 42 of the base execut- is Sue a certificate 154 (e.g. 1546, 154c) A certificate 154 

able 14 (see FIG. 6). 35 (e.g. 1546, 154c) may be associated with authorization of a 

The identification records 132 may typically identify the certificate holder (e.g. 1526, 152c) by a certification author- 
holder of the certificate 154 associated with the certificate ity 152 (or just authority 152). Associated with a certificate 
120. Although the signature 134 is associated with the 154 may be certain data 120, 118. For example, in one 
certifying authority providing the certificate 120, and itself embodiment, a certificate 154 may actually be embodied as 
holding the certificate 118, identification records 133 may AQ a frame 142 as illustrated in FIG. 4. 
identify the certifying authority 152 (e.g. associated with the la general, a certificate 154 (e.g. 1546) may be prepared 
ID 122). The signature 134 may be used by entities or by an authority 152 (e.g. 152a) using a private key 156 (e.g. 
processes needing to verify the authorization of the holder 156a) held securely in the possession of the authority 152 
(entity identified by the ID 132) of the certificate 120. (e.g. 152a). A certificate 154 (e.g. 1546), itself, may contain 

As a practical matter, a private key 128, 138 is typically 45 information such as the holder identification 158 identifying 

not stored in the clear in any non-volatile storage generally the holder to whom the authority 152 has issued the certifi- 

available. That is, a private key 128, 138 may typically be cate 154. Note that the holder 152 (e.g. 1526) may itself be 

unwrapped or loaded only dynamically to minimize the another authority 152 (e.g. 1526) to a lower level holder 152 

chance of any unauthorized access. The private key 128, 138 (e.g. lS2d). 

may optionally be stored within a cryptographic 50 The certificate 154 may also include the authority's 152 

[ co-processor, for example an additional processor 70. The signature 162. By signature 162 is meant, a digital signature 

\ cryptographic co-processor may be embodied as a chip, a as known in the cryptographic art. Also included in the 

I token, a PCM CIA card, a smart card, or the like. The private certificate 154, or linked by the signature 162 with the 

key 128 may be unwrapped in the co-processor for use only corresponding certificate 154, may be a policy 164. A policy 

within the co-processor. 5S 164 represents the extent of the authorization provided by 

The applications 40 the preprocessor 93 and the channels the certificate 154 (e.g. 154a) to the holder (e.g. 1546) of the 

96 may be stored in the data structure 114. Nevertheless, the certificate from the authority 152 (e.g. 152a) in order to 

data structure 114 may be distributed. produce cryptographic functionality. 

The library modules 16, the manager modules 18, the For example, a holder 152a* may have a certificate 1540* 

engines 20, and the support modules 22 may be stored in the 60 and private key 156a* authorizing the holder 152a* to produce 

data structure 114. In one embodiment, the data structure modules, such as cryptographic engines 20, manager mod- 

114 may all be resident in the RAM 72 in some dynamic ules 18, library modules 16, or symmetric or asymmetric 

fashion during operation of the operating system 14 func- keys 156. The policy 164a* may embody the restrictions, 

tioning in the processor 70. limitations, and authorizations extended to the holder lS2d 

The certificate 120 may be embodied as illustrated in the 65 of the certificate 154<i 

frames 142. The identification record 132 may be thought of In one embodiment, the enforcement of policies 164 may 

as a data segment 132 associated with a holder. The segment be managed in one or more of several, relatively sophisti- 
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cated ways. For example, a policy 164 might permit a 
private key of a relatively long length, such as 1024 bits, to 
be used for digital signatures 162 only. On the other hand, 
a private key 156 used to wrap symmetric keys may be 
permitted to extend only to 768 bits, and only on condition 
that the key 156 be escrowed. 

Also, rules for "composition" of policies 164 (certificated 
features or functions), or perhaps more descriptively, "super- 
position" of policies 164, may be embodied in manager 
modules 18. For example, more than a single policy may be 
loaded within a filler 12, for one of several reasons. For 
example, modules 13 from different vendors may be manu- 
factured under different authorities 152. Also by way of 
example, as in FIG. 4, a policy authority digital signature 
129, 139, certifying a respective policy 130, 140, need not 
be from the same source as a certificate authority digital 
signature 124, 134, but may be. 

Meanwhile, a manager module 18 may be programmed to 
enforce the most restrictive intersection of all features (e.g., 
certificated features or functions such as quality, crypto- 
graphic strength, etc. For example, one policy 164 (a certi- 
fied feature) may require that key -wrapping keys may be 
1024 bits long and must be escrowed. Another policy 164 in 
another module 13 in the same filler 12 may require that 
keys be only 512 bits long, but need not be escrowed. The 
cryptographic manager module 18 may require a key length 
limit of 512 bits, and require escrow also. Thus a superpo- 
sition of policies 164 may use the most restrictive intersec- 
tion of policy limitations. 

An authority 152, thus certifies 166 or provides a signing 
operation 166 for a certificate 154 for a holder. Referring to 
FIG. 5, the certification authority 152a (the root certifier 
152a) is an authority 152, to the CMC signature root 1526 
as a holder, both with respect to the certificate 1546. 

Each certificate 154, is signed using a private key 156 of 
a certifying authority 152. For example, the certifiers 152a, 
1526, 152e use private keys 156a, 1566, 15 6e, respectively, 
to sign the certificates 1546 and 154e delivered to the CMC 
signature root 1526 and server CA152e, and certificate 154; 
forwarded by the key generation module 42. 

The certificate 1546 also includes a public key 1606. A 
public key 160, in general, is one half of a key pair including 
a private key 156. For example, the private 156a, 1566, 
156c, 156d, 156e, 156/, 156g, 156fc is the matched half 
associated with the public 160a, 1606, 160c, 160a", 160e, 
160/, 160g, 160/i. The key pair 156a, 160a, is associated 
with the root certifier 152a. Similarly, the private key 1566 
may be used by the CMC signature root 1526 to certify 
166d, 166e the certificates 154J, 154<? with the signatures 
162a 1 , 162e, Thus, in turn, each of the public keys 160a*, 
160e, respectively is the public key half of the pair that 
includes the private key 156o*, 156e, respectively. 

A holder, such as the module signature authority 1524 or 
the server certification authority 152e may verify the validity 
of the public key 1606 using the signature 1626 and the 
public key 160a. Similarly, a processor entity may verify the 
validity of the certificates 154a", 154e, respectively, by 
recourse to the signature 162a*, 162e, respectively, and the 
publicly available public key 1606 responsible. 

Referring to FIGS. 5 and 6, generation of private/public 
key pairs 156, 160 and subsequent certification 166 may be 
represented by cascading certificates 154. For example, at 
the top or root of all certification authorities 152 may be a 
root certifier 152a. The root certifier 152a may generate a 
private 156a, and a public key 160a, as a key pair 156, 160. 

The root certifier 152a need have no signature 162. The 
root certifier 152a in such circumstance must be "trusted". 
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Another method, other than a digital signature 162 of a 
higher certifying authority 152, may typically be required 
for verifying the public key 160a of the root certifier 152a. 
Only one root certifier 152a (RC 152a) is needed for the 

5 entire world. In one embodiment, the root certifier 152a may 
be an entity willing and able to credibly assume liability for 
the integrity of public keys 160, and the integrity of asso- 
ciated certificates 154. For example, an insurer, or a com- 
pany known and trusted by the entire business world, may 

10 serve as a root certifier 152a. Such companies may include 
large, multinational insurance companies and banks. The 
root certifier 152a is functionally responsible to physically 
protect the secret key 156a. The root certifier 152a is also 
responsible to distribute the public key 160a. 
The root certifier 152a may authorize private/public key 

15 pairs 1566, 1606 to be created by the CMC signature root 
1526. The integrity of the public key 1606, and the identity 
1586 of the CMC signature root may be certified by a digital 
signature 1626 created by the root certifier 152a using the 

2Q private key 156a. 

Any subsequent entity, receiving a certificate 154 cascad- 
ing from the CMC signature root 1526 as a certifying 
authority 152, may verify the certificate 154. For example, 
the certificate 1546, and its contents (public key 1606, ID 

M 1586, and signature 1626) may be verified using the signa- 
ture 1626. The signature 1626 may be created using the 
private key 156a. Therefore, the signature 1626 can be 
verified using the public key 160a available to the entity to 
whom the authority of a certificate 1546 is asserted as 

30 authentication. 

The root certifier 152a may have its public key 160a 
embedded in the base executable 14. Alternatively, any 
method making the public key 160a securely available may 
be used. In this example, the base executable 14 or principal 

35 software product 14 may typically, be an operating system 
14. The base executable 14, operating system 14 or base 
executable 14 may be thought of as including everything 
that arrives in the base executable associated with a newly 
purchased, generic, software package 14. This may some- 

40 times be referred to as "the base executable 14." 

As a practical approach, the CMC signature root 1526 
may be associated with, and the private key 1566 be in the 
possession of, the "manufacturer." For example the manu- 
facturer of a base executable 14, such as a network operating 

45 system 14 may be the holder of the private key 1566 used to 
certify all public keys 160a* and associated certificates 154a" 
of the module signature authority 152. 

As a practical matter, the highest level of public key 160 
embedded in (or otherwise securely available to) a base 

50 executable 14 may be the signature root key 1606 associated 
with the certificate 1546. An instantiation of the certificate 
1546 may be embedded in, or otherwise securely available 
to, the CMC loader 90. Thus, the loader 90 may verify 
against the manufacturer's public key 1606 (available to the 

55 loader) the signature 162a" in the certificate 154d effectively 
presented by the module 13. That is, one may think of the 
certificate 1540* as being included in the cryptographic 
module 13 (engine 20) of FIG. 6 by a module vendor. 
Thus, the loader 90 may verify that a vendor is authorized 

60 to produce the modules 13 under the policy 164a* bound to 
the certificate 154d. However, the foregoing starts at the 
wrong end of the process. The signature 168 on the module 
13 is present for verification of the module by the loader 90. 
The signature 168, encrypted using the private key 156A, 

65 may be verified by recourse to (e.g. decryption using) the 
public key 160/i. The key I6O/1 is presented in the certificate 
154/t, also available with the module 13. 
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In turn, the signature 162/i on the certificate I54h, may be 
verified using the public key 160c/. The key 160c/ corre- 
sponds to the private key 156c/ used to encrypt the signature 
162h. The key 160c/ is available in the certificate 154c/ with 
the module 13. The certificate 154c/ and key 160c/ are 
verified by the signature 162c/ on the certificate 154c/ with 
the module. The signature 162c/ may be verified (e.g. such as 
by decryption or other means) using the public key 1606 of 
the CMC signature root 1526. An instantiation of this key 
1606 is available to the loader 90 with the certificate 154c/, 
as discussed above. By having the certificate 154c/ indepen- 
dently of the modules 13, the loader may thus verify each 
module 13 before loading into the filler 12 (CMC 12). 

As an example, the CMC signature root 1526 may be 
associated with the manufacturer of the base executable 14. 
The base executable 14 may be thought of as the principal 
software product 14, such as an operating system 14. By 
contrast, the CMC 12 may be thought of as a filler 12, a 
modularized segment that is required to be present within 
the base executable 14, but which may be modified, 
customized, limited, authorized, or the like, by a manufac- 
turer for a class of customers or by a suitably authorized, 
third -party vendor of modules. 

In the case of a base executable 14 that serves as a 
network operating system 14, such as Novell Netware™, the 
manufacturer, (Novell, in this example) may be the CMC 
signature root 1526. Another example may be a third party 
vendor of modules 13. A third party vendor of modules 13 
may produce, for example, engine modules 20 for insertion 
into the CMC 12, but may be a value-added reseller of the 
base executable 14 adapted with such a cryptographic 
engine module 20 or other module 13. 

For purposes of discussion, a manufacturer may be 
thought of as the maker of the base executable 14. A vendor 
or third party vendor may be thought of as the maker of 
modules 13 for inclusion in the CMC 12 (filler 12) portion 
of the base executable 14. A distributor, reseller, or third 
party reseller may be thought of as a seller of base 
executables 14 purchased from a manufacturer. The manu- 
facturer may distribute and create modules 13. A vendor of 
modules 13 may be a distributor of the base executable 14, 
also. 

Thus, a situation of great interest involves a manufacturer 
desiring to provide the base executable 14, while certifying 
a vendor's module products 13. The modules 13 may be 
integrated as part of the CMC 12 of the base executable 14 
after the base executable 14 is shipped from the manufac- 
turer. As discussed above, shipment of a base executable 14 
in some standard configuration is desirable. In a preferred 
embodiment a base executable 14 shipped into a foreign 
country having import restrictions on cryptography, may 
provide a reliable method for enabling authorized cryptog- 
raphy exactly, while disabling all other potential uses of 
cryptography. Minimum modification, interfacing, and cost 
may be provided by an apparatus and method in accordance 
with the invention, with maximum assurance of authoriza- 
tion and control, all at a reasonable processing speed. 

The CMC signature root 1526 may be responsible for 
manufacturing and exporting the base executable 14 to 
customers (users) and third- party resellers, and supporting 
software development kits (SDKs) to third party vendors. 
The manufacturer may be a maker of modules 13 also. 
Typically, the manufacturer may produce the null engine 48, 
at least. 

The module signature authority 152c/ associated with the 
ID ISSd may be that of the holder of a software development 
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kit for modules 13. A policy 164c/ bound to the certificate 
154c/ may be certified by the signature 162c/ of the CMC 
signature root's 1526 private key 1566. 
The policy 164c/ may be enforced by the manager module 

5 42 and embodies the limits on the use and strength of keys 
156c/. For example, the length (strength) of keys 156 useable 
under the policy 164c/ and the types of modules 13 may be 
controlled by statute in each country of importation for the 
base executable 14. 

10 A loader 90 from the manufacturer may control linking of 
modules 13. Thus, a third party, including a module vendor 
cannot change the limitations inherent in a key, the policy, 
or the like. 

A policy 164, in general, may define the maximum 
1S strength of the key. A module signature authority 152c/ f 
holding a particular authorized software development kit 
may create different types of keys 156 as long as each is 
within the bounds of the policy 164c/. The module signature 
authority 152c/ may also then certify a module-signing key 
20 pair 152/} authority for each module type produced and sold. 
Certificate 154/i, so signed using the private key 156c/, may 
provide a key 156/j to sign each module 13, such as the 
cryptographic modules 13 exemplified by the engine 20 of 
FIG. 6. Meanwhile a module signature authority 152c/ may 
25 certify embedded keys 160A and associated certificates 154A 
automatically by using the software development kit. 

Note that a chain or cascade of certificates 154c/, lS4h 
may be used in a module in order to have the signatures 162 
for the loader 90 to verify. The loader 90 may then verify the 
keys 160c/, 160/i using signatures 162c/, 162h of the certifi- 
cates 154c/, 154/i to authorize the loading of the module 20 
(see FIG, 6). 

Verification may be necessary in order for the loader to 

35 have the certified keys 160c/, I6O/1, 1606 necessary for 
verifying the module signature 168. That is, a vendor may 
use a software development kit containing a module signa- 
ture authority 152c/ to create some number of module 
signing key pairs 152/i. 

4 0 The private keys 156/i may be used to sign 166m with a 
signature 168 every module 13 created. Note that the mod- 
ules 16, 10, 42 in the base executable 14 of FIG. 6 may all 
be thought of genetically as modules 13 as in FIG. 1. The 
certificate hierarchy 154/i, 154c/, 1546 of the module 13 may 

45 all be verified by the loader 90 using the appropriate public 
keys 160c/, 1606, to verify the respective signatures 162/i, 
162c/ from the certificates 154/i, 154c/. 

The server certifying authority 152e (CA 152e) may be 
produced by the manufacturer based a on CMC signature 

50 root 152. The server certificate authority 152e may be 
embodied in the server 60 (see FIGS. 2,6) on a serve r-by- 
server basis. Thus, a server 60 may generate keys 156; or 
pairs as shown in FIG. 6. Thus, the server 60 is able to certify 
by a key generation manager 42 keys 160 generated by that 

55 server 60. 

A private key 156 may preferably be unique to an indi- 
vidual server 60 so that there is no need to provide a globally 
exposed private key 156. The private key 15 6e of the server 
certificate authority 152e of FIG. 6 may be the only private 

60 key 156 embedded in a base executable 14 or operating 
system 14 hosted by a server 60. This may be very important 
for providing signatures 162; for certifying 166; other keys 
160; and IDs 158; signatures 162. 
As a practical matter, by embedding is meant alternate 

65 methods that may be implemented in the server 60 in another 
manner well adapted to dynamic loading. For example, the 
private key 156e may not necessarily need to be embedded, 
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as in the illustrated example. Rather, the key 156e may 
simply be "securely available," such as by reading from a 
secure hardware device. Thus, a key 156e may be securely 
available to the CMC 12 in the server 60 and function as well 
as if actually embedded. The expression embedded should 
be interpreted broadly enough to include this "securely 
available" approach. This is particularly true since dynamic 
loading in combination with cryptographic techniques 
herein for verification make such methods readily tractable. 

In general, a private key 156 may be used to produce 
certifying signatures 162. A key 156 may also be used to 
decrypt data received when it has been encrypted using a 
corresponding public key 160 to ensure privacy. 

Both keys 156, 160 may be necessary for both privacy and 
integrity, but they are 5 used at opposite ends of a commu- 
nication. That is, for example, the CMC signature root 1526 
may use the public key 160 of the module signature author- 
ity to assure privacy of communication to the module 
signature authority I52d. The module signature authority 
152d, may use the public key 1606 of the CMC signature 
root 1526. Each 1526, 152d may use its own private key 
1566, \S6d to decrypt received messages. Integrity may be 
verified by a signature 162 authored using an appropriate 
private key 1566, 156a\ Meanwhile, authenticity of 
communications, such as a signature 162c/, created using a 
private key 1566, may be verified by an entity using the 
corresponding, published, public key 1606. 

As a matter of good cryptographic practice, integrity and 
confidentiality (privacy) may rely on separate keys. A mod- 
ule 13 may employ a plurality of private/public key pairs 
156/160. One pair may be used for channel confidentiality. 
A separate and distinct pair may be used for channel 
integrity. 

The certificates 154 in the base executable 14, for 
example in the module 13, and loader 90 illustrate authen- 
tication of the cascade of certificates. Initially, the modules 
13 of FIG. 6 are signed by the signature 168 created with the 
private key lS6k 

The public key 160/i may be used to verify the signature 
168. References to decryption of signatures 168 mean 
verification, which requires some amount of decryption. 

The authenticity of the public key 160/t is assured by the 
signature 162h on the certificate 154/t. The signature 162/t is 
verified using the public key 160rf in the certificate 154d 
available. 

The authenticity of the public key 160d is assured by the 
signature 162 d oil the certificate 1544. The signature 162d is 
verified using the public key 1606 in the certificate 1546 
available. 

This illustrates the practical limit to authentication. The 
following is not separately illustrated in the architecture, but 
could be implemented. The authenticity of the public key 
1606 could be assured by the signature 1626 by obtaining 
the certificate 1546. The signature 1626 would have to be 
verified using the public key 160a in the certificate 154a 
available. Note that some other mechanism must be used to 
verify the certificate 154c. 

A server may generate keys for cryptographic operations. 
For example, a separate set of keys 156/ may exist for each 
client 58 on the network 56. 

Asymmetric systems are more computationally expensive 
than symmetric systems. The key length used in asymmetric 
systems is typically much longer than that for symmetric 
systems, (e.g. asymmetric keys may be l-2k bits long, 
versus 40, 64, or 128 bits for typical symmetric keys). In 
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cryptographic protection schemes, an asymmetric algorithm 
may be used to protect a symmetric key that will be 
distributed to a client 50 encrypted using the client's public 
key 160 and decrypted by the client's corresponding private 

5 key 156. A shared secret key may be used for shared 
symmetric key communication in a network 56. Thus, the 
server CA private key 156e may be used to generate a 
signature certifying other public/private key pairs 160, 156. 
That pair 156, 160 may be used to certify another pair or to 

lQ distribute a symmetric key pair. 

A certificate 154 is needed for a public key 160, and must 
be signed (162) using the corresponding private key 156. A 
private key 156, for example, is used to certify any public 
key 160 created in the key generation module 42 of FIG. 6. 
That is, the key generation module 42 may generate a key 

15 pair 156, 160; in which the server CA private key 156e is 
used to sign the certificate 154; created by the key generation 
module for the cryptographic libraries. The server CA pri- 
vate key 156 may be used to sign all certificates 154 (with 
included public key 160) generated by the CMC filler 12 in 

20 the base executable 14 of operating system 14 hosted on the 
server 60. 

A server key (not shown), which may be symmetric, may 
be generated by the key generation module 42 and used for 
key wrapping. All keys that should be kept secret may be 

25 wrapped for being transmitted or stored secretly outside of 
the CMC 12, such as in a cryptographic library 36. 

Certain of the attributes of a key 156 (algorithm, archive, 
type, etc.) may be wrapped along with the key 156 before 
being passed outside of the CMC 12. Thus a private half of 

30 an asymmetric key pair, or a symmetric, secret key should be 
wrapped preceding any export or output from the CMC 12. 

The libraries 16 may be (typically must be) application- 
specific, and anything transmitted to them may be consid- 
ered to be outside of the control of the CMC 12 once it is 

3S transmitted to the library 16. 

Escrow is controlled by a manager 14 such as the key 
generation manager 42, a cryptographic manager 18. In any 
case, every key 156; generated should be saved throughout 
its useful life. A key 156; may be saved, typically, in an 

40 encrypted format in a secure environment called a key 
archive 170. The archived key 156; may first be encrypted, 
and the key 160 to that encryption is the escrow public key 
160k. The corresponding public key 160; is also archived, 
although it maybe publicly available. 

45 The escrow authority 152/ may be an entity generating a 
public/private key pair 160,156 for each server 60 in order 
to encrypt (privacy protect) private keys 156 before archival. 
Thus, the escrow authority 152/ may have a private key 156/ 
unique to itself, which is used to sign 162k the certificates 

50 154/: for all of those public/private key pairs 156/r, 160k. The 
escrow authority 152/ may receive its private/public key pair 
156/ 160/ from a key escrow root 152c. The key escrow root 
key 156c may certify the key 160/ held by the escrow 
authority 152/ The manufacturer of the base executable 14, 

55 (Novell, in the example above, may be (i.e. control) the key 
escrow root 152c. 

The certificate 154c held by the key escrow root 152c may 
itself be signed by the root certifier 152a certifying the 
public key pair 160c of the key escrow root 152c. Thus, the 

60 key escrow path (certifications 166, cascade) of certificates 
154 and keys 156, 160 may have its source in the root 
certifier 152a, just as the CMC signature root 1526 does. 

An escrow authority 152/ may hold the private key 156/ 
to the archive holding the encrypted, escrowed keys 156, 

65 The archive 170 may actually be inside the server 60. Thus, 
the holder of the base executable 14 has all the encrypted 
keys 156. 
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However, a government or some such agency may require 
certain keys of the escrow authority 152/. A manufacturer, 
such as Novell, the operating system manufacturer, in the 
example above, could also serve this function as well as 
being the key escrow root 152c. This may be advantageous 5 
for the same reasons that a manufacturer would be the 
signature root 1526. The escrow authority 152/ may give to 
the agent the escrow private key 156/ for the specific server. 
This may be the private half 156k of an escrow key 156 that 
the keys 156 in question were encrypted in for archiving. 3Q 
The government may then go to the user of the server 60 to 
get access to the archive 170 in the server 60 of the owner 
of all the keys 156/ 

Some governments may want to be the escrow authority 
152/ for all escrow keys. The government may unlock the ^ 
key archive 170 whenever desired. In certain countries, the 
key archive 170 may be in possession of a trusted third party 
or the government. For example, the key generation module 
42 may need to create keys 156;, encrypt them, and send 
them as data to a trusted third party acting for the govern- 
ment to control the archive 170. 

From the above discussion, it will be appreciated that the 
present invention provides controlled modular cryptography 
in an executable designed to be embedded within another 
executable such as a network operating system, or the like. %s 
Cryptographic capability is controlled by a manager module 
operating according to a policy limiting the capability and 
access of other modules, particularly that of the crypto- 
graphic engine. Thus, a system 14 (a base executable 14) 
may be provided having nearly all of the capabilities of the 3Q 
"filler" 12 intact. A very limited interface between a filler 12 
and its internal engine selection 20 provides for examination 
of engines 20 by regulatory authority. Moreover, the 
restricted interfaces 30, 32 between the engines 20 and the 
remaining modules 13 of the filler 12 present great difficulty 3S 
to those who would modify, circumvent, or replace any 
portion of the filler 12 (CMC 12) in an attempt to alter its 
capabilities. Meanwhile, asymmetric key technology pro- 
vides for enforcement of all controls, thus providing privacy 
and integrity for all communications, operations, exchang- 4Q 
ing of keys, and the like. 

The present invention may be embodied in other specific 
forms without departing from its spirit or essential charac- 
teristics. The described embodiments are to be considered in 
all respects only as illustrative, and not restrictive. The scope 45 
of the invention is, therefore, indicated by the appended 
claims, rather than by the foregoing description. All changes 
which come within the meaning and range of equivalency of 
the claims are to be embraced within their scope. 

What is claimed and desired to be secured by United 50 
States Letters Patent is: 

1. An apparatus having modules for executing controlled 
modular cryptography in a processor of a computer, the 
apparatus comprising: 

a base executable programmed to be executable on the 55 
processor, and comprising a loader for dynamically 
loading and linking a filler, comprising modules, into 
the base executable, the loader linking the modules to 
one another to operate as an integrated portion of the 
base executable; 60 
an engine module dynamically loadable into the base 
executable to be executable on the processor to operate, 
in accordance with a controlling policy, selected cryp- 
tographic execu tables for an application operably asso- 
ciated with the computer; 65 
a support module dynamically linkable to interface 
between the engine module and the base executable; 



a library module dynamically linkable to interface 
between the application and the filler, and 

a manager module dynamically linkable to interface 
between the engine module and the library module. 

2. The apparatus of claim 1, wherein the engine module 
comprises a null engine. 

3. The apparatus of claim 1 wherein the library module 
includes an interface to the application, an interface to the 
manager module, and an interface to the base executable as 
exclusive interfaces to the library module. 

4. The apparatus of claim 1 wherein the manager module 
includes an interface to the library module, an interface to 
the engine module, and an interface to the base executable 
as exclusive interfaces to the manager module. 

5. The apparatus of claim 1 wherein the engine module 
includes an interface to the support module and an interface 
to the manager module as exclusive interfaces to the engine 
module. 

6. The apparatus of claim 1 wherein the support module 
includes an interface to the engine module and an interface 
to the base executable as exclusive interfaces to the support 
module. 

7. The apparatus of claim 1 wherein the engine module is 
isolated from directly interfacing with the application and 
the base executable. 

8. The apparatus of claim 7 wherein the engine module is 
isolated by the library module from directly interfacing with 
the application and isolated by the support module from 
directly interfacing with the base executable. 

9. The apparatus of claim 7 wherein the manager module 
enforces interface limitations contained in the controlling 
policy and corresponding to enablement of interfaces 
between the modules. 

10. The apparatus of claim 9 wherein the manager module 
enforces outside interface limitations contained in the con- 
trolling policy and corresponding to enablement of inter- 
faces between the modules and the base executable and 
interfaces between the modules and the application. 

11. The apparatus of claim 10 wherein the manager 
module enforces, upon the engine module, engine limita- 
tions contained in the controlling policy and corresponding 
to enablement of selected cryptographic functions of the 
engine modules. 

12. The apparatus of claim 11, wherein the manager 
module is adapted to enforce the engine limitations by 
verifying a digital signature associated with the engine 
module and a digital signature associated with the base 
executable. 

13. The apparatus of claim 1, wherein the manager 
module is programmed to contain a first policy, the loader is 
further procrammed to load a second policy, and the man- 
ager module is programmed to formulate a composite policy 
within limits of both the first policy and the second policy. 

14. The apparatus of claim 1, wherein the loader is 
adapted to enforce loading limitations by verifying a cryp- 
tographic filler signature associated with the filler. 

15. An apparatus comprising a digital computer having a 
processor programmed to execute applications and to 
execute a plurality of executable modules comprising: 

a base executable loadable into the computer to perform 
a base function, the base executable module being 
provided with a slot adapted to receive a filler module; 

the filler module containing a unique property recogniz- 
able by the base executable, and alterable exclusively 
by an authorized creator of the filler module; 

a loader module integral to the base executable, pro- 
grammed to verify the presence of the unique property, 
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and to dynamically load the filler module only if the management module, and to be invoked by applications 

unique property verifies correctly. operating in the processor, and wherein the management 

16. The apparatus of claim 15, wherein the unique prop- module is effective to control access to the engine by the 
erty is a digital signature. library module. 

17. The apparatus of claim 15, wherein the filler module 5 31. The article of claim 28, wherein the engine is a 
further comprises a plurality of modules and the loader cryptographic engine and the management module is pro- 
module is programmed to provide linking between the grammed to direct use of a cryptographic key by the engine, 
plurality of modules in a layered hierarchy containing levels, thc comprising a p 0U cy block storing a policy 
and in which a linking of a first module of the plurality of effe ctive to provide controlling data useable by the manage- 
modules at a first level to a second module of the plurality M mcnt modu[c {Q Hmit ^ u$c of tfac cryptographic key by thc 
of modules at a second level defines an allowability of an en g me 

invocation of the second module by the first module. 32 ^ artide of claim 31 wherein the usc by the engirie 

18. The apparatus of claim 15, wherein the filler module comprises construction of the cryptographic key by the 
comprises an engine. engine 

19. The apparatus of claim 18, further comprising a J5 33. The article of claim 32, wherein the engine and pohcy 
management module executable by the processor to isolate afe comb ined in an engine module stored in the memory 
the engine from access by unauthorized applications. devic ^ and k which me unique property is associated with 

20. The apparatus of claim 19 further comprising a library the engine module 

module executable to invoke the management module, and M ^ artidc of clajm 25> wnerein thc unique property 

to be invoked by the applications executing in the processor, 2Q fe a sigaature . 

and, wherein the management module is executable to 35 ^ arddc of claim 26> wherein mc cnginc ^ a 

control access to the engine by the library module. cryptographic engine. 

21. The apparatus of claim 19, further comprising a 36. The article of claim 26, further comprising a support 
policy, and wherein the engine is a cryptographic engine and bk)ck sk)rmg a support module tQ interface between the 
the management module is programmed to control use of M engine and ^ base executable> and effec tive to limit access 
one or more cryptographic keys by the engine, in accordance of ^ engine tQ the base exeC utable, thereby limiting exten- 
with the policy. s j Qn Q f f eatures 0 f t he engine through extension of the base 

22. The apparatus of claim 21 further comprising an executable. 

engine module containing the engine and policy combined, 37 ^ af(icle of claim 2 ^ wnerein the unique property 
and in which the unique property is associated with the 3Q fe a digital signature> and the loader module further corn- 
engine module. prises a cryptographic block containing a cryptographic key 

23. The apparatus of claim 18, wherein the engine is a cffec tivc to verify the digital signature, 
cryptographic engine. 38. Amethod for limiting integration of software modules 

24. The apparatus of claim 18, further comprising a mto a base module executable on a processor of a computer, 
support module to interface between the engine and the base 35 the method comprising: 

executable, and executable to limit access of the engine to U1 . . . 

iL , 4 Lt tI _ . ... . „ , „ ftf providmg a base module executable by the processor, the 

the base executable, thereby limiting extension of features of ** 6 . . J . * j 

4 i . , ' . f( ,;. base module having a slot for receiving a filler module, 

the engine through extension of the base executable. . . - ■ * n jTj. . \ 

IS. An article Comprising a memory device having blocks and having an integrally programmed loader to control 

for storing executables and data, the article including a first 4Q loadm S of * c filler module ^ 

block storing a plurality of executable modules, executable providing a filler module containing an engine effective to 

on a processor, the block comprising: be executed by the processor, the filler containing a 

a base module loadable into the processor to perform a uni 4 ue P ro P ert V recognizable by the loader and unal- 

base function, the base module being provided with a terablc b V other ^an an authorized creator of the filler 

slot adapted to receive a filler module, 45 module; 

a loader module integral to the base module, executing the base module by the processor; 

the filler module effective to be executed by a processor, executing the loader by the processor; 

the filler module containing a unique property recog- verifying by the loader the presence of the unique prop- 

nizable by a loader, and unalterable by other than an erty in the filler module; 

authorized creator of the filler module, and 50 loading dynamically the filler module only after the loader 

the loader module programmed to verify the presence of verifies the unique property successfully. 

the unique property, and to dynamically load the filler 39 . fbe method of claim 38, wherein the filler module 

module only if the unique property verifies correctly. comprises an engine, 

26. The article of claim 25, wherein the filler module 40. The method of claim 39, further comprising: provid- 
comprises an engine. 55 mg a management module executable by the processor; and 

27. The article of claim 26, wherein the engine is a null execu ting the management module to isolate the engine 
engine effective to support execution of the filler while from unaulnor ized access by an application, 
providing no effective cryptographic functionality. 41 ^ melhod of daim 39> whcrcin the engine com . 

28. The article of claim 26 further comprising a manager prfses a cryptographic eogine . 

block storing a management module effective to isolate the 60 42 ^ mcthod of claim 38> comprising: 

engine from access by unauthorized applications. . , . , 

29. The article of claim 28 wherein the management P r0VldlD S a sn ^ 0Ti modulc; and 

module is programmed to provide key management, includ- executing the support module by the processor to limit 

ing key escrow and storage of encrypted backup copies of extension of the engine by isolating the engine from 

cryptographic keys. 65 accessing the base executable. 

30. The article of claim 28, further comprising a library 43- The method of claim 38 further comprising: 
block storing a library module authorized to invoke the providing a library module; and 
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executing the library module by the processor to control 
usage by the application of functions of the manage- 
ment module. 

44. The method of claim 41, further comprising: 
providing a policy comprising policy data; 5 
executing the management module effective to control use 

of a cryptographic key useable by the engine; and 
controlling by the management module, in accordance 
with the policy data, access by the engine to the use of 3Q 
the cryptographic key. 

45. The method of claim 44, wherein the unique property 
is a digital signature. 
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46. The method of claim 38 wherein the filler module 
comprises a plurality of modules, the method further com- 
prising: 

linking by the loader, the plurality of modules to one 
another in a layered hierarchy containing levels and in 
which a linking of a first module of the plurality of 
modules at a first level to a second module of the 
plurality of modules at a second level defines an 
allowability of an invocation of the second module by 
the first module. 
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